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ABSTRACT 


This  paper  describes  modeling  and  simulation 
technologies  used  to  simulate  the  electrical  systems  of 
Army  vehicles  using  Matlab/Simulink  coupled  with 
graphical  user  interface  software.  The  models  were  built 
using  Mathworks’  Matlab/Simulink  software  in 
conjunction  with  the  SimPowerSystems  Toolbox,  a 
toolkit  provided  by  Mathworks  that  provides  models  of 
basic  electrical  components  such  as  capacitors  and 
inductors,  in  addition  to  more  advanced  components 
such  as  diodes  and  IGBT’s.  The  current  results  of  this 
ongoing  effort  are  presented  and  discussed. 

INTRODUCTION 


Fast  and  accurate  modeling  of  electrical  systems  can 
prove  complicated,  due  to  the  linear  and  non-linear 
elements  in  the  system.  For  instance,  suppose  a 
parallel  RLC  circuit  is  represented  by  the  following 
equation: 


V, 

R 


+  — 
L 


rlv-dt 


dV  V 

+  C — L  =  — Lu(t-0.1),  [1  ] 
dt  R. 


Modeled  in  Simulink,  it  might  resemble  Figure  1. 


described  with  non-linear  equations.  To  directly  enter 
the  differential  equations  corresponding  to  vehicular 
electrical  systems  in  Simulink  would  be  time-consuming 
and  probably  cumbersome,  not  to  mention  difficult  to 
debug  for  particularly  complicated  system  schematics. 
Use  of  SimPower  allows  modeling  the  physical  electrical 
system  directly  and  the  software  constructs  the 
appropriate  equations. 

SIMPOWER 

This  toolkit  provides  “black  box”  components  such  as 
voltage  sources,  resistors,  inductors,  diodes,  etc.  which 
enable  a  user  to  construct  an  electrical  model  by  simply 
connecting  the  proper  simulated  components  together, 
mimicking  an  electrical  schematic. 

Similar  to  the  concept  of  “black  box”  or  object-oriented 
methodology  in  software-engineering, 
SimPowerSystems  lets  the  user  “plug”  the  electrical 
components  together,  to  make  a  functioning  model, 
while  the  state-space  equations  which  model  the 
Simulink  circuit  are  automatically  generated  and  remain 
hidden  from  the  user.  This  enables  a  much  more  rapid 
development  of  an  electrical  model  from  a  schematic. 

COMPONENT  MODELING 


During  the  course  of  the  effort,  challenges  were 
encountered  with  respect  to  certain  devices  not  provided 
by  the  SimPowerSystems  Toolbox.  Common  power 
electronic  components  such  as  rectifiers  and  inverters 
were  developed  to  ensure  a  smooth  system  integration 
effort.  These  components  were  developed  to  the 
appropriate  level  of  fidelity  to  ensure  that  although  the 
model  produced  accurate  results,  it  did  so  in  a 
reasonable  time  frame. 

INVERTER 


Figure  1 


If  the  system  were  comprised  only  of  one  parallel  RLC 
circuit,  then  this  would  simplify  matters.  However, 
vehicular  electrical  systems  are  more  complicated  and 
may  have  multiple  series  and/or  parallel  RLC  circuits,  in 
addition  to  electronic  devices  that  are  more  accurately 


Figure  2  Three-Phase  Steady  State  Inverter 

Typically  three-phase  inverters  are  used  to  supply  three- 
phase  loads.  For  vehicles,  the  inverter  is  typically 
needed  to  convert  DC  power  to  AC  power  for  the  typical 
induction  motors  used  in  hybrid  electric  applications. 

During  the  course  of  the  investigation,  a  three-phase 
inverter  model  was  developed  as  a  component  level- 
drop  in  for  various  vehicle  models  in  development 
consideration.  Due  to  some  overhead  introduced  by 
SimPowerSystems,  it  was  decided  to  use  Simulink  to 
develop  a  mild  three-phase  inverter,  and  in  this  instance 
the  appropriate  equations  were  known.  The  following 
equations  describe  the  duty  cycles  of  the  three  phases, 
where  Vbat  is  the  voltage  of  a  vehicle  battery  and  t  is 
time: 

0.5  *  Vbat  *  ( sin(2  *  pi  *  60  *  t)  ) 

0.5  *  Vbat  *  ( sin(2  *  pi  *60*1-2*  pi/3)  )  ,  [  2  ] 

0.5  *  Vbat  *  ( sin(2  *pi*60*t  +  2*  pi/3)  ) 


STATEFLOW 

In  augmenting  the  relevance  of  these  models,  test  cases 
using  various  hypothetical  mission  scenarios  had  to  be 
studied.  The  development  of  these  scenarios  and 
feeding  it  into  the  models  via  a  usable  data  interface  was 
another  challenge  in  itself.  One  application  tool  studied 
was  the  use  of  Stateflow,  a  toolbox  provided  by 
Mathworks  which  aids  with  the  type  of  event-driven 
modeling  a  mission  scenario  requires. 

Stateflow  is  a  graphical  design  tool  enabling  the  user  to 
model  event-driven  behavior.  It  is  based  on  finite  state 
machine  (or  finite  automaton),  whereby  each  “state” 
reflects  the  condition  a  system  is  in.  A  state  may  be 
entered  or  exited  when  certain  (non-)conditional  events 
occur  which  require  a  change  in  the  system. 


SimPowerSystems  models.  At  a  certain  time  t,  a 
vehicular  load  will  be  turned  on/off,  and  Stateflow  sends 
the  appropriate  command  signal  to  the  model. 

In  an  attempt  to  enable  a  user  to  have  a  friendly 
interface  in  order  to  evaluate  the  model  results,  it  was 
decided  that  being  able  to  read  a  mission  scenario  from 
an  Excel  spreadsheet  would  be  a  feasible  solution. 

EVENT  MODELING 

The  decision  to  look  at  spreadsheet  based  input  forced  a 
number  of  programming  issues  in  terms  of  setting  up  a 
simulation  design  via  Stateflow  and  Simulink.  First,  a 
programming  solution  to  extract  data  from  the 
spreadsheet  and  feed  it  to  the  Simulink  model  had  to  be 
created.  Next,  due  to  programming  language 
constraints,  a  specific  format  for  the  data  had  to  be 
created.  Finally,  a  parallel  state  chart  had  to  be  set  up  to 
send  overlapping  signals  to  the  Simulink  model  (the  term 
“overlapping”  in  this  case  refers  to  the  fact  that  signals 
indicated  certain  loads  were  turned  on/off  simultaneously 
or  at  overlapping  time  intervals).  Within  the  state  chart, 
dynamically-sized  arrays  were  created  depending  upon 
the  number  of  on/off  events  there  were  for  a  particular 
device. 


API  Programming 


Device  # 

Name 

Start 

Duration 

On/Off 

1 

Master  Power 

00:00:10 

00:00:20 

1 

1 

Master  Power 

00:00:30 

00:00:10 

0 

2 

Fuel  Pump 

00:00:10 

00:00:20 

0 

2 

Fuel  Pump 

00:00:30 

00:00:10 

1 

Figure  3  Spreadsheet  Input 

It  was  decided  that  vehicle  loads  that  would  be  turned 
on/off  would  have  a  start  time  and  a  duration  time  (how 
long  it  was  supposed  to  be  on/off).  As  mentioned 
previously,  the  on/off  events  for  the  devices  could 
overlap,  which  would  be  realistic  for  a  given  mission 
scenario.  Figure  3  shows  a  simple  test  case  developed 
to  test  the  interaction  of  the  Matlab  programming  scripts, 
Stateflow  toolbox,  and  Simulink  model. 


ttstChart 


For  the  purposes  of  the  ongoing  effort,  Stateflow  is  being 
used  as  a  control  signal  interface  to  the 


Figure  4  Stateflow  Parallel  State  Chart 

Since  it  was  not  known  in  advance  how  many  times  a 
particular  device  load  would  be  turned  on  and  off,  it  was 
necessary  to  use  the  Stateflow  API  (application 
programming  interface)  in  order  to  dynamically  size 
array  variables  which  tracked  the  on  and  off  times  of  the 
loads.  The  API  enables  a  programmer  to  access  a 
Stateflow  chart  via  Matlab  scripting  commands  which  sift 
through  the  Stateflow  objects. 

Path  forward 

Some  of  the  challenges  associated  with  the  Stateflow 
application  included  computation  of  parallel  states,  which 
led  to  overlapping  signals  being  sent  after  their 
appointed  time.  This  timing  issue  appears  to  be  a 
function  of  the  way  Stateflow  evaluates  parallel  states 
and  may  simply  be  a  hard  limitation  which  cannot  be 
overcome.  In  addition,  a  methodology  for  describing 
non-discrete  events  may  have  to  be  conceived  (e.g., 
such  as  for  a  light  dimmer  switch  where  there  is  a  range 
of  lighting  available  between  on  and  off).  The  Stateflow 
API  is  a  powerful  tool  that  can  be  used  to  dynamically 
create  a  state  chart  on  the  fly,  and  the  possibility  of 
creating  a  state  chart  from  a  script  (as  opposed  to  the 
manual  creation  employed  in  this  effort)  exists. 

LAB  VIEW 

In  attempting  to  speed  up  the  development  of  a 
graphical  user  interface,  it  was  decided  to  study 
Labview.  Labview  is  a  software  tool  typically  used  in 
data  acquisition  and  analysis  environments  and  enables 
a  visual  GUI  to  be  developed  rapidly  via  its  plug  and  play 
components  and  gauges.  Thus,  to  demonstrate  the 
performance  of  the  models  to  the  casual  user,  a 
graphical  user  interface  was  developed  that  displayed 
the  relevant  system  data.  However,  integration  issues 
with  Matlab/Simulink  presented  additional  obstacles  that 
had  to  be  overcome  with  mapping  conventions  using 
National  Instruments’  Simulation  Interface  Toolkit,  the 
software  interface  designed  to  link  Labview  with 
Matlab/Simulink.  For  instance,  it  was  found  that 
occasionally  trying  to  map  a  gauge  readout  to  a  Simulink 
/  SimPowerSystems  measurement  component  caused 
inconsistent  system  errors. 


In  addition,  the  capabilities  of  the  Java  and  Python 
programming  languages  are  still  being  explored  as 
alternatives  to  Labview. 


CONCLUSION 

Constructing  an  integrated  event-driven  model  with 
multiple  software  toolkits  presented  interesting 
challenges  from  a  systems  engineering  perspective. 
Tools  which  were  thought  to  work  right  out  of  the  box 
with  Simulink  (such  as  the  Simulation  Interface  Toolkit), 
required  more  finesse  and  debugging  than  anticipated. 
Though  developing  a  baseline  model  seems  readily 
accessible  to  the  casual  user,  a  more  thorough  model 
which  may  one  day  be  used  to  augment  design  trade 
studies  may  require  a  slightly  altered  approach. 

For  instance,  perhaps  Labview  does  not  scale  well  when 
required  to  interface  with  hundreds  of  vehicle  loads  in 
the  model.  This  may  force  a  user  to  simply  using  just 
the  native  graphics  capabilities  with  Matlab  in  order  to 
prevent  this.  Future  work  should  include  a  more 
integrated  and  detailed  system. 
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Figure  5  Example  Labview  Screenshot 


